home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Almathera Ten Pack 3: CDPD 3
/
Almathera Ten on Ten - Disc 3: CDPD3.iso
/
scope
/
001-025
/
scopedisk1
/
dnet
/
readme
< prev
next >
Wrap
Text File
|
1995-03-18
|
8KB
|
222 lines
DNET V1.01 Alpha, BSD4.3 end.
DNET (c)Copyright 1987 Matthew Dillon, All Rights Reserved
Matthew Dillon
891 Regal Rd
Berkeley, Ca. 94708
...!ihnp4!ucbvax!dillon USENET
dillon@ucbvax.Berkeley.edu ARPANET
forum: ...!ihnp4!ucbvax!cory!dnet
dnet%cory@ucbvax.berkeley.edu
Remember, this is an ALPHA release.
CLEAN -shell script to clean up object files
MAKE -shell script to make in client, dnet, server, and test
bin -holds binaries, add this directory to your path
client -holds client utilities sources
dnet -holds dnet driver source
doc -HOLDS FURTHER DOCUMENTATION. ALSO SEE THE SOURCE AND
HEADER FILES!
lib -holds the support library for client and server source.
server -holds server utilities sources
test -used to test DNET entirely on the system (i.e. run both
ends of the driver in different directories). holds
source to test program initiator.
PREDEFINED VARIABLES:
The enviroment variables DNETDIR is normally set to a directory
which you should create for the rendezvous UNIX level sockets. If
set you can run dnet, all servers, and all clients from any
directory and they will setup their UNIX sockets in the right place.
This variable should have a hanging slash on it ex: ~/.DNET/
BASIC THEORY, UNIX END:
The DNET driver accepts connections from clients over UNIX domain
sockets. It multiplexes and packetizes the data, sends it to
whatever is on descriptor 0 (usually your tty). It receives data
from the serial port, de-packetizes it, demuxes it, and sends it to
the proper client. Additionaly, it receives open requests from
the remote end and tries to connect to the proper server.
All the servers are UNIX domain sockets in DNETDIR (if the
enviroment variable DNETDIR is not defined, then in whatever
directory they were run from). The name of the socket in the
directory is .DNET.# where # is the port number in decimal. DNET
itself creates a socket called DNET.PORT .
BASIC THEORY, AMIGA END:
The communications protocol, obviously, is the same. In fact, it is
completely symetrical (there is no such things as master/slave
here).
The DNET driver on the Amiga opens the serial port with the default
preferences (or current modes if you have a terminal program active
at the time you run DNET).
Servers on the Amiga create public message ports named DNET.PORT.#,
while the driver creates DNET.PORT . (look at the Amiga support
library dnetlib.c to see how the interface works).
GETTING IT RUNNING TO YOUR AMIGA: (MUCH DIFFERENT FROM V1.00)
Before you can use DNET you must ensure that a valid PATH is
setup on the Amiga side to DNET's binaries. You must modify the
.login on the UNIX side and add the DNETDIR enviroment variable
as specified above, and must ensure that your UNIX path is setup
to point to associated binaries on the UNIX side.
DNET WILL PROPERLY SET THE PARITY/DATABITS/PROTOCOL. YOUR
PREFERENCES SHOULD CONTAIN THE CORRECT BAUD RATE AS THERE IS
NO PROVISION TO CHANGE IT AT THE MOMENT.
(1) RUN DNET. You will get a small terminal window set at
7 bits even parity. This is a dinky thing and is only
meant to allow you to log in and startup the server on
the remote end.
CLOSE WINDOW: quit's DNET.
MENU BUTTON: START's DNET
^C (BREAK CLI#): Abort DNET protocol and go back to
DNET terminal window
(2) dialup and log into your 4.2/3 UNIX system
(3) start any servers on the UNIX system 's_shell &;s_copy &'
NOTE: You do not need to start any servers to use FTERM.
NOTE: Servers may still be active from your last session.
(4) start dnet on the UNIX system with 'dnet'
The terminal window should automatically go away. DNET
is now running. An FTERM is automatically RUN (assuming
your path is setup properly).
You can also execute other various client programs, such
as more FTERMs, TERMs, and PUTFILES from your Amiga
(assuming you started the servers on the UNIX end).. you
can start the servers on the UNIX end from your TERM/FTERM
windows also.
You can also startup servers on the Amiga end. Specifically,
by doing a 'RUN S_COPY', you can then do a PUTFILES from
the UNIX end to send things to your Amiga.
AUTO RESTART FEATURE:
At any time, if one end of the connection goes away (you quit DNET,
for instance), you can RESTART the connection by restarting the
driver that died. (I.E. you don't have to hangup, log back in,
and start from scratch).
KILL FEATURE:
Not completely debugged, but theoretically if, say, the UNIX end
goes away, you can BREAK the DNET on the Amiga side and it *should*
EOF all active clients... causing them to abort.
NOTE: The destination directory that PUTFILES files go to on the remote
host is the one you were in when you started the server. This applies
to any server you start, whether on the amiga or the UNIX host. I
suggest you make a special directory and start the S_COPY server in
that.
NOTE: Closing all active clients does NOT kill DNET... you must BREAK
it and hit the CLOSE gadget in it's window.
*** UNIX SERVERS ACCESSED FROM AMIGA CLIENTS ***
S_COPY: File transfer server. When running on the UNIX end, you
can then use the PUTFILES command on the Amiga end to send files
or ENTIRE DIRECTORY STURCTURES from the Amiga to the UNIX
host.
S_SHELL: Rlogin server. When running on the UNIX end, you can then
use the TERM command on the Amiga end to start up a new
login window.
NOTE: These windows do not automatically adjust the tty rows
and columns.
(internal): FAST CSH server. This is an internal server in DNET. You
use the FTERM command on the Amiga end to start up a new
shell window. Response is much better as data flow s
going through one less process.
NOTE: These windows will AUTOMATICALLY adjust the tty rows
and columns when you resize the window. The disadvantage
is that they run on unnamed PTY's, and thus do not show up on
'who'
*** AMIGA SERVERS ACCESSED BY UNIX CLIENTS:***
S_COPY: File Transfer server. When running on the Amiga, you can
use the PUTFILES command on the UNIX end to transfer
files or entire directory structures from your UNIX account
to your Amiga.
S_SHELL: Access a CLI from the UNIX end. use 'DSOC 8196' from
the UNIX end to connect.
This requires two things. (1) My PIPE: device must be
mounted, and (2) a NEWCLI must be run on the PIPE: as
follows:
NEWCLI <NIL: >NIL: pipe:shell/t scriptfile
KILLING DNET ON THE UNIX END WITHOUT HANGING UP:
The Utility program QUITDNET will talk to the local DNET which will
send a message to the DNET running on your UNIX system causing it
to quit. You can tell it quit by looking at the Rx/Tx L.E.Ds on
your modem ... when the UNIX system starts echoing character's
normally.
Then, close all client sessions, BREAK the DNET on your Amiga, and
quit DNET by hitting the close gadget on the DNET window.
DNET will never "give up"... it will continue retrying forever or until
you ^C it.
Restoration Sequence... logging off, hanging up.
(1) Ensure all connections are closed and DNET is idle
(2) BREAK (^C) DNET and all servers... they should all exit.
(3) hangup the phone (2) can be swapped with (3)
close DNET's window. Any servers left on the UNIX system will
still be running and available next time you log on.
QUICKIE DESCRIPTION OF LOW LEVEL PACKET THEORY:
DNET uses a windowed-packet scheme, as in transmission windows... up
to 4 packets can be sent before one of them is acked. Each packet is fully
checked with three check bytes (one on the header, and two for the data). If
a packet fails it is ignored. If the receiver detects a missing packet it
requests it be resent. If the sender doesn't get an ack within a given
timeout it sends a CHECK packet, which asks the receiver if it got it or not
(rather than just resend the packet, which might take a while).
The channel multiplexing is embedded in the packet data... that is,
you might have the data for several channels in a single packet, so
maximum throughput is maintained even when you have a lot of little things
going on.
TODO:
-Too Much Buffer Copying